<HTML>
<HEAD>
<!-- Created by texi2html 1.56k + clip patches and <A href="http://www.clip.dia.fi.upm.es/Software">lpdoc</A> from WebDB.texi on 8 January 2003 -->

<LINK rel="stylesheet" href="WebDB.css" type="text/css">
<TITLE>The WebDB WWW Database Interface               - Introduction</TITLE>
</HEAD>
<BODY> 
Go to the <A HREF="WebDB_1.html">first</A>, <A HREF="WebDB_1.html">previous</A>, <A HREF="WebDB_3.html">next</A>, <A HREF="WebDB_9.html">last</A> section, <A HREF="WebDB_toc.html">table of contents</A>.
<P><HR><P>


<H1><A NAME="SEC2" HREF="WebDB_toc.html#TOC2">Introduction</A></H1>

<P>
 


<P>
<CODE>WebDB</CODE> provides a way to create and customize a 
<A NAME="IDX1"></A>
<EM>Relational Database</EM> and/or a 
<A NAME="IDX2"></A>
<EM>WWW interface</EM> to access it. <CODE>WebDB</CODE> provides a simple WWW interface based on 
<A NAME="IDX3"></A>
<EM>HTML</EM> forms which allows the user to access the data stored in any database, local to <CODE>WebDB</CODE> itself or remote. 


<P>
In the first case, the tables are designed according to the definition of filebased persistent predicates, using the library <CODE>persdb</CODE> [GCH98] and are maintained directly by <CODE>WebDB</CODE>, allowing the system administrator to create, destroy or edit the tables. In the second case, the data is stored in remote SQL databases, so that <CODE>WebDB</CODE> just provides an interface to them through the primitives espeficied in the library <CODE>persdb_sql</CODE> [CCG98]. 


<P>
As we will see, the information can be accessed in two different ways. We could say that <CODE>WebDB</CODE> provides a 
<A NAME="IDX4"></A>
<EM>single table interface</EM> and a 
<A NAME="IDX5"></A>
<EM>multitable interface</EM>. 


<P>
Through the first way, the interface to access a table is created automatically on every access. This is achieved by defining each table field according to an 
<A NAME="IDX6"></A>
<EM>html_format</EM> type, which is translated by a template into the right HTML input type for the given field, for example, a checkbox, an input box or a textarea. 


<P>
The system administrator can add new types and define tables according to them. Of course, <CODE>WebDB</CODE> provides an interface to develope this task in an automatic way. 


<P>
The 
multitable interface or, as we will see in further sections, the complex query option provides an interface to make queries over a database view in both, Prolog or SQL syntax, by offering a window where the user can write them. 


<P>
Settings in <CODE>WebDB</CODE> are kept in 
<A NAME="IDX7"></A>
<EM>configuration files</EM>, and are customizable, as well as types and templates. The system administrator can customize them on line, without needing to stop the system, through the interface provided by the application itself. 



<UL>
<LI><A HREF="WebDB_2.html#SEC3">Data Storage</A>
<LI><A HREF="WebDB_2.html#SEC6">WebDB Interface</A>
<LI><A HREF="WebDB_2.html#SEC11">WebDB Types and Templates</A>
<LI><A HREF="WebDB_2.html#SEC12">Defining SQL remote Databases</A>
<LI><A HREF="WebDB_2.html#SEC13">Version/Change Log (WebDB)</A>
</UL>



<H2><A NAME="SEC3" HREF="WebDB_toc.html#TOC3">Data Storage</A></H2>

<P>
As mentioned above, the data <CODE>WebDB</CODE> operates on can be local or located at remote SQL databases. In both cases, <CODE>WebDB</CODE> provides a WWW interface to access it in a transparent and comfortable way. 


<P>
These two kinds of data storage are based upon the same concept: 
Persistent Predicates. The idea is that whatever changes might have been done on one of these predicates survive across executions. This way, no matter whether the system stops, or even crashes, we will always have a consistent state of the predicate, which is quite an useful thing if we want to implement a database. If Prolog is halted and restarted, the predicate the new Prolog process sees is right in the state it was in the very moment the old process was halted, provided that no changes to the external storage were done in the meantime by other processes or the user himself. 


<P>
Actually, there are two different implementations of 
persistent predicates: 

<UL>
<LI>File based persistent predicates, which local tables are based upon, and

<LI>SQL based persistent predicates, which is the way <CODE>WebDB</CODE> implements the tables located on remote SQL databases.

</UL>

<P>
The first method can be used for storing smaller amounts of data that we will call 
<A NAME="IDX8"></A>
<EM>local data</EM>. In <CODE>WebDB</CODE> this kind of persistent predicates are also used to manage most of the internal information the system needs to handle the operations the services it provides resemble. In a wider context, e.g. the Prolog world, it seems an easy and efficient way to achieve persistence, saving the state of the predicates through executions, which, up to now, is something Prolog systems where quite lack of. 


<P>
The second method provides a very high-level natural way to access, from a Prolog program, larger amounts of data in SQL database relations. According to this method, persistent predicates are linked to tables in external databases so that the predicates actually reside in such tables. These tables are seen from the Prolog side as ordinary predicates. 


<P>
In the next figure, we can appreciate the interaction between <CODE>WebDB</CODE> and these two kinds of persistent predicates as well as the system's architecture: 


<P>
<IMG SRC="autofigarchitecture.jpg" ALT="Image:autofigarchitecture.jpg"> 


<P>
As we can see in the figure, the <CODE>WebDB</CODE> server provides its services through the WWW. These services basically consist of an interface to query the database and, in the case of the system administrator, manage the system. 




<H2><A NAME="SEC4" HREF="WebDB_toc.html#TOC4">The Generic Database Server: dbserver</A></H2>
<P>
This part of the <CODE>WebDB</CODE> documentation is aimed to describe its database server, <CODE>dbserver</CODE>, which provides the users with services to access a given database. This server has been developed as a <CODE>CIAO prolog</CODE> 
<A NAME="IDX9"></A>
<EM>active module</EM> and is basically an executable which publishes its IP address in order to allow client programs to use its services. Client programs are invoked with the CGI protocol by the web server and connect to the active module to request server actions. 


<P>
This server also uses the capabilities provided by the filebased persistent predicates to manage the multiple aspects of the database it is bound to, for example, to keep the current state of a search or the current description and type of a given table, or even the text messages which are output as a result of any interaction with the system. 



<UL>
<LI><A HREF="WebDB_2.html#SEC5">Launching dbserver</A>
</UL>



<H3><A NAME="SEC5" HREF="WebDB_toc.html#TOC5">Launching dbserver</A></H3>

<P>
In order to make the database accessible from the web, the dbserver is launched through the CGI <CODE>startdbserver.cgi</CODE> and its standard error output is redirected to a file called <CODE>dbserver.log</CODE>, located on the <CODE>private</CODE> directory. This way, any misbehaviour or problem occurred will be registered and, therefore, solved more easily. The steps the dbserver carries out at this point follow: 


<P>
First of all, the dbserver processes the contents of the file <CODE>dbserver_ini.pl</CODE>. This file is created during the installation and contains important data relative to the directories of the database and its URLs. 


<P>
The next step is to read the configuration files for the database. Database customization basically lies on these files, which contain information regarding the 
html_format 
<A NAME="IDX10"></A>
<EM>types</EM> and 
<A NAME="IDX11"></A>
<EM>templates</EM> and their translation into <CODE>PiLLoW</CODE> terms, as well as information about the searches lifetime, the translation between 
html_format and SQL 
types and the remote SQL databases the system is bound to. 


<P>
Once all this information has been processed, dbserver can start the processing of data regarding the database tables. So, dbserver enables for future queries both kinds of tables, local tables based upon filebased persistent predicates and remote tables based upon SQL-based persistent predicates. 


<P>
The next step is to start the statistics procedure by resetting the date of initialization for the dbserver. This information can be accessed through the service provided by the option <CODE>status</CODE> lying on the maintenance front page . 


<P>
Finally, if necessary, dbserver generates a <CODE>maintenance front page</CODE> which is the first part of the manager interface, and initializes all those other persistent predicates embedded in the system which are used for inner tasks such as keeping a trace of the current state of queries and the text of the user interface messages. 




<H2><A NAME="SEC6" HREF="WebDB_toc.html#TOC6">WebDB Interface</A></H2>

<P>
The <CODE>WebDB</CODE> interface is aimed to be an easy and straightforward way to query and manage a database. As we can see in the figure, this interface is composed by several stages. Each one offers the right interface for a given service, many of them only allowed to the user administrator. 


<P>
<IMG SRC="autofigInterface.jpg" ALT="Image:autofigInterface.jpg"> 



<UL>
<LI><A HREF="WebDB_2.html#SEC7">Manager Interface</A>
<LI><A HREF="WebDB_2.html#SEC8">The Inspect/Insert/Modify Data option</A>
<LI><A HREF="WebDB_2.html#SEC9">The Complex Query option</A>
<LI><A HREF="WebDB_2.html#SEC10">Clients of the Generic WebDB Distribution</A>
</UL>



<H3><A NAME="SEC7" HREF="WebDB_toc.html#TOC7">Manager Interface</A></H3>

<P>
Let's concentrate on the manager interface as the common user interface is quite simple and consists of a restricted version of the manager search interface. 


<P>
The first stage of the manager or administrator interface is a maintenance front page where the following options are provided: 



<UL>
<LI><EM>Start the System</EM>, obviously used to start the dbserver.

<LI><EM>System Status</EM>, which provides information about the dbserver status and statistics about the system's usage.

<LI><EM>Remote SQL Databases Connection Management</EM> is the door to an interface which enables the system administrator to connect <CODE>WebDB</CODE> to remote SQL databases and unlink it from a previously added one. Through this interface, it is possible to collect the information <CODE>WebDB</CODE> needs in order to accessing the tables of a given database. Besides, it provides information about the remote SQL databases the system is already linked to.

<LI><EM>Inspect/Insert/Modify Data</EM>, provides an interface where the user can operate on each table of the database individually.

<LI><EM>Complex Query</EM>, provides another interface to operate on the database. This interface is quite similar to a Prolog top level, an environment where the user can make his own queries according to Prolog and SQL syntax standards.

<LI><EM>Modify Messages and Text Settings</EM>, provides a list with all the system messages and the text settings and allows the system administrator to edit them.

<LI><EM>Create/Destroy Tables</EM>, allows the system administrator to create new filebased tables for the current database or destroy any of the already existing as well as unlink the system from remote SQL tables.

<LI><EM>Edit Tables Types</EM>, allows the system administrator to edit the type of any field of a filebased table or to add or delete them.

<LI><EM>Reload Templates and Update DB Types</EM>. Once the

configuration files have been changed, this option reloads them and updates the system with the new configuration. 
<LI><EM>Stop the System</EM>, halts the system and updates the information stored upon filebased persistent predicates.

</UL>

<P>
Additional information must be given about the fourth and fifth options: 




<H3><A NAME="SEC8" HREF="WebDB_toc.html#TOC8">The Inspect/Insert/Modify Data option</A></H3>

<P>
Once the user has decided on which table to operate on, this option displays the system consult interface. Through this interface the user can choose which operation to carry out. 


<P>
Initially, the system administrator, can choose among the following operations: 

<UL>
<LI><EM>Search</EM>: Sequential search. The results of the query are displayed one by one as the user requests them.

<LI><EM>Overview</EM>: All the tuples that instantiate the query are displayed in a table, but just as prolog facts, without the additional information supplied by the fields types.

<LI><EM>Full search</EM>: As in the case of the <EM>Overview</EM> operation, all the tuples that instantiate the query are displayed, but in this case with the additional information of its field types. Besides, through this option, the user can edit the results too.

<LI><EM>Insert element</EM>: Allows the user to insert a new element, which has to be completely specified, e.g. no field of the form can remain empty. Besides, the system tests that the element to be inserted doesn't exist in the table already.

<LI><EM>Delete element</EM>: Deletes all the tuples that instantiate the query.

<LI><EM>Modify element</EM>: Allows the user to edit a given tuple of the table.

</UL>

<P>
If the user is not an authorized client, the operations allowed will only be <EM>Search</EM>, <EM>Overview</EM> and <EM>Full search</EM> which, in this case, will not allow the user to edit the results of a previous query. 


<P>
Note that when any query is made over a database table, the information written into the form fields is taken as prolog terms. This way, any empty field of the form is translated into a free variable and therefore will unify all the corresponding arguments of the given table. 


<P>
Besides, <CODE>WebDB</CODE> provides three different search modes: 

<UL>
<LI><EM>Normal search mode</EM>: This is the most restrictive search mode. The results of the query will be just those tuples which exactly match the fields specified.

<LI><EM>Case insensitive search mode</EM>: In this mode upper and lower case is indistinct.

<LI><EM>Wildcards search mode</EM>: Implements a search where wildcards can be used. Special characters are:

<DL COMPACT>

<DT>*
<DD>
Matches any string, including the null string. 
<DT>?
<DD>
Matches any single character. 
<DT>[...]
<DD>
Matches any one of the enclosed characters. A pair of characters separated by a minus sign denotes a range; any character lexically between those two characters, inclusive, is matched. If the first character following the [ is a ^ then any character not enclosed is matched. No other character is special inside this construct. To include a ] in a character set, you must make it the first character. To include a `-', you must use it in a context where it cannot possibly indicate a range: that is, as the first character, or immediately after a range. 
<DT>|
<DD>
specifies an alternative. Two regular expressions A and B with | in between form an expression that matches anything that either A or B will match. 
<DT>{...}
<DD>
groups alternatives inside larger patterns. 
<DT>Quotes a special character (including itself).
<DD>
</DL>
</UL>



<H3><A NAME="SEC9" HREF="WebDB_toc.html#TOC9">The Complex Query option</A></H3>
<P>
This option is fully available for both authorised and not authorised clients. As mentioned above, it provides an interface to query the database in Prolog and SQL syntax. It is necessary to select the view the tables involved in the query lay on. 


<P>
When only local tables are involved in the query, the predicates allowed in this environment are restricted in order to avoid any eventual misuse. This set of allowed predicates can be classified in the next categories: arithmetic and relational operators, connectors (i.e. ',' and ';') and the tables of the database itself. 


<P>
On the other hand, in the case of tables belonging to remote SQL databases, it is quite recommendable to control which views are to be accessible for the system users and with which rights in order to prevent the SQL tables from being manipulated unduly. 


<P>
As an on-line guide for the user, this option displays a list of the tables the database consists of. This includes information about the arity of the tables, the physical database where they are located and the types of their fields. 


<P>
There are three possible answers for a complex query: 

<UL>
<LI><EM>No elements found</EM> if there were no matches for the query.

<LI><EM>Unsuccesful query</EM> if the query tried to attempt against the system integrity or any predicate involved didn't exist.

<LI><EM>Complex Query Response</EM>. In this case the output is a table with the name of every variable written in the query and their values.

</UL>



<H3><A NAME="SEC10" HREF="WebDB_toc.html#TOC10">Clients of the Generic WebDB Distribution</A></H3>

<P>
This part of the <CODE>WebDB</CODE> documentation is aimed to describe the CGI clients which are included by default with the distribution of <CODE>WebDB</CODE> and form the interface described in the previous section. 


<P>
These clients use the services provided by the server to query the database or manage the system. From this point on, the number of clients added only depends on the system administrator and the number and nature of the services required by any specific case. 


<P>
Each client is firmly related to the services provided by the server. In most cases, this relation is an injective application, as we can see: 



<UL>
<LI><EM>dbcommonselection</EM> &#60;-&#62; <CODE>get_relationsdb</CODE>

<LI><EM>dbcommonclient</EM> &#60;-&#62; <CODE>consultdb</CODE>

<LI><EM>dbselection</EM> &#60;-&#62; <CODE>get_relationsdb</CODE>

<LI><EM>dbclient</EM> &#60;-&#62; <CODE>consultdb</CODE>

<LI><EM>dbcomplexquery</EM> &#60;-&#62; <CODE>complex_query</CODE>

<LI><EM>dbcreatetable</EM> &#60;-&#62; <CODE>create_destroy_table</CODE>

<LI><EM>dbeditselection</EM> &#60;-&#62; <CODE>select_table_to_edit</CODE>

<LI><EM>dbeditclient</EM> &#60;-&#62; <CODE>edit_table</CODE>

<LI><EM>dboptions</EM> &#60;-&#62; <CODE>consultdboptions</CODE>

<LI><EM>dbtemplates</EM> &#60;-&#62; <CODE>dbtemplates</CODE>

<LI><EM>dbserverstatus</EM> &#60;-&#62; <CODE>status</CODE>

<LI><EM>dbconnect_DB</EM> &#60;-&#62; <CODE>connect_to_DB</CODE>

<LI><EM>dbserverstop</EM> &#60;-&#62; <CODE>dying</CODE>, <CODE>die</CODE>

</UL>

<P>
Going back to the first figure, we can see that, in fact, every component of <CODE>WebDB</CODE> can be located on distant hosts on the WWW, as they get through with one another using the 
HTTP protocol. This leaves an open door for distributed databases due to its interconnectivity. 




<H2><A NAME="SEC11" HREF="WebDB_toc.html#TOC11">WebDB Types and Templates</A></H2>

<P>
<CODE>WebDB</CODE>'s customizability lies on a series of files, file based persistent predicates and predicates which constitute a system of types and templates in order to generate the HTML representation of every table. In the nex figure we can appreciate the interaction of each of these components with one another and with dbserver. 
 
<IMG SRC="autofigtemplates.jpg" ALT="Image:autofigtemplates.jpg"> 


<P>
Let's describe these components: 

<UL>

<LI><EM>html_options</EM> are a set of .html files processed by the dbserver both when it is started and when the system administrator reloads the templates of the system through the operation <EM>Reload Templates and Update DB Types</EM>, available at the maintenance front page. These templates are parametric. So, the user can set them to the right values and customize the database.

It is important to bear in mind that although these files are parametric, their structure, as well as their name, have to be respected. Moreover, the user must not delete any of them. 

So, in order to customize the settings, from the background color to the representation of the html tables, the user only needs to change the parameters of these files and reload them, using the previously mentioned operation. 

<LI><EM>text_options</EM> is one of the persistent predicates embedded in the system mentioned in previous sections. It is used to store all the messages and text the system uses when interacting with a client. As we can see in the figure, this component is linked to dbserver in both ways. This means that, although dbserver uses it to produce the right text and messages, it is also able to edit them. To do so, the system administrator must choose the <EM>Modify Messages and Text Settings</EM> operation.

<LI><EM>dbtables_desc</EM> is the next of these system embedded persistent predicates. It stores the definition of all the tables the database consists of, both remote and local. To define a table, the system administrator has two options:


<UL>
<LI>Create it through the interface provided by <CODE>WebDB</CODE> using the operations <EM>Create/Destroy Tables</EM> and <EM>Edit Tables Types</EM> of the maintenance front page.

<LI>Create it by adding an entry in the file <CODE>DBDATADESC/db_desc/dbserver:dbtables_desc-2.pl</CODE>. This entry must be written in the following format:


<PRE>
'dbserver:dbtables_desc'( 
&#60;&#60;Table_name&#62;&#62;(
	&#60;&#60;Type 1&#62;&#62;(&#60;&#60;Field description 1&#62;&#62;, &#60;&#60;Length 1&#62;&#62;), 
	&#60;&#60;Type 2&#62;&#62;(&#60;&#60;Field description 2&#62;&#62;, &#60;&#60;Length 2&#62;&#62;), 
	
	&#60;&#60;Type n&#62;&#62;(&#60;&#60;Field description n&#62;&#62;, &#60;&#60;Length n&#62;&#62;)), 
	&#60;&#60;Situation&#62;&#62;,
	&#60;&#60;Creation Date&#62;&#62;).
</PRE>

Besides, it is possible to link the tables laying in an SQL remote database through the operation <EM>Remote SQL Databases Connection Management</EM>. 

<CODE>WebDB</CODE> distribution includes an example of these types and templates for a given database and surely the best way to make a new one is by pattern matching. 

Each of these types need to have their corresponding entry in the file <CODE>html_format</CODE> located on the directory <CODE>DBDATADESC/db_types</CODE> which will be described next. 

In every case, the second argument of <CODE>dbserver:dbtables_desc/3</CODE> points out whether the table is local, by setting that field to the value `local', or remote, by writing the identifier of the view for the SQL database. That kind of identifier is defined in the filebased persistent predicate <CODE>sql_location/2</CODE> which, just like the <CODE>DBDATADESC/db_types/html2sql.pl</CODE>, is described in the next section (Defining SQL remote Databases). 

</UL>

<LI><CODE>type_info/3</CODE> and <CODE>type_val_info/4</CODE> are used to obtain the translation between a type defined for a field in <EM>dbtables_desc</EM> and its corresponding template of <EM>html_format</EM>, which is the component to be described next. <CODE>type_info</CODE> is used to get the <EM>html_format</EM> template of a table field and its description before making any query and, on the other hand, <CODE>type_val_info</CODE> gets the contents of a table field after the query has been made.

<LI>html_format

is a 
<A NAME="IDX12"></A>
<EM>macro</EM> which provides an interface to use the primitives provided by the library <CODE>PiLLoW</CODE> in a transparent way. An entry of <EM>html_format</EM> can be equivalent to a large piece of <CODE>PiLLoW</CODE> code and, therefore, it contributes to make things simpler and more customizable. 
</UL>



<H2><A NAME="SEC12" HREF="WebDB_toc.html#TOC12">Defining SQL remote Databases</A></H2>
<P>
This is fundamentally achieved thanks to the library <CODE>persdb_sql</CODE> which provides and interface to remote SQL databases located on Win95/NT machines. In order to use the facilities provided by that library, <CODE>WebDB</CODE> needs the predicate <CODE>sql_location/2</CODE> and the file <CODE>html2sql.pl</CODE>, described next: 



<UL>

<LI><CODE>sql_location.pl</CODE> is an SQL based persistent predicate that contains entries <CODE>WebDB</CODE> uses to define the fact <CODE>sql_persistent_location/2</CODE> (see the documentation of <CODE>persdb_sql</CODE> [CCG98]) for each remote SQL database view linked to <CODE>WebDB</CODE>.

<LI><CODE>html2sql.pl</CODE> contains instances of the predicate html2sql/2 which provide the translation between the macros defined in <EM>html_format</EM> and their equivalent SQL types.

<LI><CODE>sql2html.pl</CODE>, in the opposite direction, allows to find the right html_dormat representation type for a given SQL type.

</UL>



<H2><A NAME="SEC13" HREF="WebDB_toc.html#TOC13">Version/Change Log (<CODE>WebDB</CODE>)</A></H2>

<DL COMPACT>

<DT><STRONG>Version 0.5#12 (1999/11/6, 22:2:26 MET)</STRONG>
<DD>
Updated documentation to lpdoc-1.9 formats. (Manuel Hermenegildo)

<DT><STRONG>Version 0.5#11 (1999/9/16, 12:52:5 MEST)</STRONG>
<DD>
Added lock file to prevent the system from being started several times (Jose Manuel Gomez Perez)

<DT><STRONG>Version 0.5#10 (1999/9/3, 10:58:16 MEST)</STRONG>
<DD>
Generic client interface added (Jose Manuel Gomez Perez)

<DT><STRONG>Version 0.5#9 (1999/6/1, 19:35:14 MEST)</STRONG>
<DD>
Automatic distribution procedure completed. (Manuel Hermenegildo)

<DT><STRONG>Version 0.5#8 (1999/5/31, 17:11:11 MEST)</STRONG>
<DD>
Readmes now automatically generated from documentation. (Manuel Hermenegildo)

<DT><STRONG>Version 0.5#7 (1999/4/23, 13:14:44 MEST)</STRONG>
<DD>
Naive graphical statistics added (Jose Manuel Gomez Perez)

<DT><STRONG>Version 0.5#6 (1999/4/21, 11:58:39 MEST)</STRONG>
<DD>
Text statistics added (Jose Manuel Gomez Perez)

<DT><STRONG>Version 0.5#5 (1999/4/20, 13:9:27 MEST)</STRONG>
<DD>
Infrastructure for system status info added (Jose Manuel Gomez Perez)

<DT><STRONG>Version 0.5#4 (1999/3/29, 19:57:47 MEST)</STRONG>
<DD>
HTML templates revised (Jose Manuel Gomez Perez)

<DT><STRONG>Version 0.5#3 (1999/3/23, 18:58:21 MET)</STRONG>
<DD>
Automatic link to remote SQL databases through ODBC added (Jose Manuel Gomez Perez)

<DT><STRONG>Version 0.5#2 (1999/2/10, 12:29:33 MET)</STRONG>
<DD>
Corrected lack of generality at the edit tables interface (Jose Manuel Gomez Perez)

<DT><STRONG>Version 0.5#1 (1999/2/10, 12:28:51 MET)</STRONG>
<DD>
Complex query with restricted preds. completed (Jose Manuel Gomez Perez)

<DT><STRONG>Version 0.5 (1998/7/23, 13:26:0 MET DST)</STRONG>
<DD>
Started autodocumentation. (Manuel Hermenegildo)

<DT><STRONG>Version 0.1#1 (1998/3/18)</STRONG>
<DD>
Updated maintenance interface. (Jose Manuel Gomez Perez)

<DT><STRONG>Version 0.1 (1998/3/18)</STRONG>
<DD>
Added recursive treatment of relations (base case). (Jose Manuel Gomez Perez)

<DT><STRONG>Version 0.1 (1998/2/20)</STRONG>
<DD>
Started automatic documentation. (Jose Manuel Gomez Perez)
</DL>

<P><HR><P>
Go to the <A HREF="WebDB_1.html">first</A>, <A HREF="WebDB_1.html">previous</A>, <A HREF="WebDB_3.html">next</A>, <A HREF="WebDB_9.html">last</A> section, <A HREF="WebDB_toc.html">table of contents</A>.
</BODY>
</HTML>
